Henk Arendse

De ontwikkeling van AI (Artificial Intelligence) is opmerkelijk hard gegaan de afgelopen jaren. Ik wilde weleens weten of AI ook echt geschikt is voor het ontwikkelen van software. Daarmee bedoel ik niet het genereren van een losse functie met ChatGPT ("vibecoding"), maar het bedrijfsmatig ontwikkelen en onderhouden van grote systemen. Er is maar één manier om dat uit te vinden: zelf doen.

Lees over een programmeerproject met behulp van AI, met verrassende onthullingen over softwareontwikkeling in de praktijk.

Welke AI?

Er zijn meerdere AI-systemen die geschikt zijn voor het ontwikkelen van programmatuur. Dit zijn de zgn. "programming agents", bijvoorbeeld: Copilot, Gemini CLI of Claude Code.

Dat zijn AI-systemen die de programmacode en de ontwerpdocumenten kunnen wijzigen, zonder dat je zelf voortdurend copy & paste moet doen vanuit een zgn. "chatbot". Dat scheelt tijd, want het kopiëren van bv. 30 regels code naar 12 verschillende plaatsen in 4 verschillende computerprogramma's is een secuur karwei.

Ik heb gekozen voor de programming agent Gemini CLI (van Google), vooral omdat je met de gratis versie heel veel kunt doen.

Welk systeem?

Ik heb Gemini CLI gebruikt om hiermee uitbreidingen te ontwikkelen voor mijn Supernova static website generator.

De Supernova website generator

Supernova is een bestaand systeem. Dat is een gangbare situatie: de meeste softwareontwikkeling wordt gedaan voor bestaande systemen. Wat doen softwareontwikkelaars dan met die bestaande systemen? Wij (softwareontwikkelaars) maken uitbreidingen op het systeem ("nieuwe features") en lossen problemen en fouten op. Denk bij "problemen" aan functionaliteit die niet handig werkt voor de gebruiker. Bij een "fout" is de functionaliteit niet correct. In beide gevallen wordt de bestaande software aangepast.

Supernova is een klein systeem, met hooguit 10 ontwerpdocumenten en 20 bestanden met daarin de programmacode ("scripts") die door één ontwikkelaar wordt onderhouden. Een groot systeem heeft honderden ontwerpdocumenten en duizenden scripts met daarin in totaal misschien wel miljoenen regels programmacode en tientallen of honderden softwareontwikkelaars. Dat is natuurlijk wel een heel groot verschil en maakt het moeilijker, ook voor de AI. Een groot systeem introduceert altijd extra complicaties en maakt het extra complex om nieuwe technieken zoals AI in te zetten.

Welke programmeertaal?

Het Supernova-systeem is gemaakt met de Python programmeertaal.

Python programmacode

Niet alle programmeertalen worden even goed ondersteund door AI. Programmeertalen die veel op internet en Github te zien zijn, worden het best ondersteund. Softwareontwikkeling met talen als Python, JavaScript, TypeScript, HTML, CSS, PHP, SQL, Visual Basic for Excel etc. wordt daarom goed ondersteund door AI.

Maar over oude talen zoals bijvoorbeeld COBOL en dBase III is veel minder te vinden op internet; die talen worden minder goed ondersteund door AI.
Hetzelfde geldt voor talen uit besloten omgevingen, zoals ABAP (de programmeertaal van het SAP ERP-systeem) en Infor 4GL (de taal van het Infor LN ERP-systeem).

Welke activiteiten?

Om de vraag "is AI geschikt voor softwareontwikkeling?" te kunnen beantwoorden, is het nuttig om te weten wat een softwareontwikkelaar zoal doet. Spoiler alert: dat is veel meer dan het intypen van briljante programmacode.

Gebaseerd op meer dan 40 jaar ervaring weet ik dat softwareontwikkelaars de meeste tijd besteden aan de volgende activiteiten:

• Zoeken en lezen
• Denken en praten
• Ontwerpen
• Programmeren
• Reviewen
• Documenteren
• Testen
• Fouten oplossen

Resultaten per activiteit

Hieronder leg ik per activiteit eerst kort uit wat ik ermee bedoel. Daarna beschrijf ik of AI daarbij nuttig was in dit programmeerproject. Samen levert dit een goed totaalbeeld op waarmee de vraag of AI geschikt is voor softwareontwikkeling kan worden beantwoord.

Zoeken en lezen

We besteden waarschijnlijk de meeste tijd aan zoeken, lezen en proberen te begrijpen wat we lezen. Dat lijkt misschien vreemd, maar een volwassen systeem heeft vele ontwerpdocumenten en bestanden ("scripts") met daarin in heel veel regels programmacode. Vaak gemaakt door collega's; soms door collega's die helemaal niet meer bij het bedrijf werken. En ook al heb je de relevante documenten en code wel zelf gemaakt: na een jaar ben je echt wel vergeten wat je toen allemaal bedacht en opgeschreven hebt. Dus we moeten veel zoeken en lezen.

Als we nieuwe functionaliteit moeten gaan toevoegen aan het systeem of bestaande functionaliteit moeten gaan verbeteren, dan moet dat heel precies ingepast worden. Daarvoor moeten we 'onder de motorkap' kijken. Dat begint bij de ontwerpdocumenten. Eerst het juiste document vinden, dan zoeken op het betreffende onderwerp, lezen en de interne werking van het systeem proberen te begrijpen. Dat is nodig om te bedenken hoe we de nieuwe functionaliteit daarin kunnen passen.
Vervolgens duiken we in de programmacode. Ook daar weer: zoeken naar code van de huidige functionaliteit, lezen en begrijpen wat er gebeurt. Dat is nodig om te bedenken hoe we de nieuwe of gewijzigde functionaliteit in de programmacode invoegen.

En als we eenmaal aan het programmeren zijn, dan lezen en zoeken we nog steeds heel veel; vooral in de programmacode. We zoeken naar bestaande functies die we kunnen hergebruiken om een deel van ons werk te doen. We zoeken naar stukjes code die we kunnen kopiëren en aanpassen. We zoeken naar oplossingen voor vergelijkbare problemen ("hé, dat probleem hadden we een paar jaar geleden ook. Hoe hebben we dat toen opgelost? Waar kan ik dat vinden?").

Zo hebben we elke dag heel veel vragen, waardoor we voortdurend moeten zoeken in documenten en programmacode.

Kan AI helpen?
Kan AI helpen bij het zoeken? Jazeker, AI kan daar heel goed bij helpen. AI is heel goed in het zoeken in teksten. Vooral als er bij het zoeken "begrip" van de situatie nodig is, dan is AI daarin een stuk beter dan de klassieke find-tools van een teksteditor. Je kunt haar bijvoorbeeld eerst vertellen wat het onderwerp is waar we aan gaan werken. Dan kun je de opdracht geven: "Lees de ontwerpdocumenten en de programmacode. Zoek hierin naar functionaliteit voor ons onderwerp. Vat de resultaten samen. Geef gedetailleerd aan waar je de gebruikte informatie hebt gevonden". Dat laatste is handig om te hebben, maar ook om de AI te kunnen controleren.

Hieronder een voorbeeld waarin Gemini CLI zoekt in de programmacode naar de juiste plaats om een specifieke aanpassing te maken. Het zoekmechanisme komt me bekend voor. Zo zoek ik zelf ook. Meestal heb je een redelijke verwachting van de plaats waar je moet kijken. En als je het daar niet vindt, dan probeer je wat anders. Het verschil is dat de AI het veel sneller doet.

Gemini CLI op zoek naar de juiste plaats om de aanpassingen te maken.

Denken en Praten

We hebben de ontwerpdocumenten en de programmacode van de bestaande software onderzocht en we weten hoe het systeem werkt. We kunnen nu een oplossing gaan bedenken voor de nieuwe of gewijzigde functionaliteit.

Dit is een creatief proces waarbij ik graag overleg met een collega. Alleen al het probleem uitleggen aan iemand anders kan soms enorm nuttig zijn. En andersom word ik door collega's ook gevraagd om mee te denken en te praten. Het beeld dat een softwareontwikkelaar een nerd is die met niemand praat, klopt niet. We praten veel.

Kan AI helpen? Kan AI helpen bij de meningsvorming? Jazeker, AI kan daar heel goed bij helpen. Leg het probleem aan de AI voor en vraag om een oplossing. Geef je mening over de aangedragen oplossing. Of geef zelf een oplossing en vraag aan de AI wat ze daarvan vindt. Samen kom je altijd tot betere ideeën. Zo werkt het ook met de AI. Het vraag- en antwoordspel met de AI levert veel inzicht op.

Let op: de AI is altijd erg beleefd en optimistisch. Ze vindt mijn ideeën vaak geweldig ("U heeft een uitstekend punt en een zeer efficiënte suggestie!"). Dat geeft mij natuurlijk wel een goed gevoel, maar het is niet zo nuttig. Je moet doorvragen. "Wat zijn de zwakke punten van mijn plan?", "Wat zijn de risico's?" of "Hoe kan het beter?".

Vraag dit ook voor de oplossingen die de AI zelf aandraagt. Heel enthousiast geeft ze dan een lijst met risico's van haar eigen plan, en punten die ze in eerste instantie gemist had. Nuttig! Zo kom je al chattend tot een goede oplossingsrichting.

In discussie met Gemini. Ze geeft nuttige feedback op een idee van mij. Het gebruik van een theme.toml file is een goede suggestie, waar we nog verder over gaan praten.

Nadeel is dat je hierdoor minder contact hebt met je collega's. Dat is natuurlijk jammer. Extra teamactiviteiten dus! Voor softwareontwikkelaars die geen collega's in de buurt hebben, kan dit vraag- en vraag-en-antwoordspel met de AI een geweldige verrijking zijn.

Ontwerpen

Het denken en praten met de collega's en de AI heeft nu een "oplossingsrichting" opgeleverd. Kunnen we dan nu eindelijk gaan programmeren? Nee, nog niet. We moeten dan eerst een ontwerpdocument maken. Pas als je alles netjes uitwerkt en opschrijft, wordt het duidelijk welke functies je allemaal moet maken of aanpassen.
We kunnen dan met behulp van het ontwerpdocument een betere inschatting maken van hoeveel tijd dit gaat kosten en wat de risico's zijn (elke aanpassing van software heeft een risico op het introduceren van fouten).
Het ontwerpdocument kan aanleiding zijn om de oplossing te heroverwegen, bijvoorbeeld als het veel meer tijd gaat kosten dan beschikbaar is. Misschien moeten we voor deze release niet alle problemen oplossen. Beter één ding goed, dan twee dingen half.

Een ontwerpdocument geeft ook continuïteit. In het vak zeggen we dan: "Als je vanavond onder de bus loopt, dan kunnen we morgen gewoon verder werken aan de hand van jouw ontwerpdocument". Heel geruststellend!

Niet elke softwareontwikkelaar heeft er zin in om dit soort documenten te schrijven. Het is veel leuker om direct de programmacode te schrijven, nu de discussie over de aanpak nog vers in het geheugen zit. Maar toch, het maken van een ontwerpdocument is heel nuttig en moet eerst gebeuren.

Kan AI helpen? Kan AI helpen bij het maken van het ontwerpdocument? Jazeker, heel goed. Als de discussie met de AI over de oplossingsrichting (zie vorige activiteit) uitgekristalliseerd is, dan geef je haar de opdracht: "maak hiervoor nu een ontwerpdocument". Binnen een paar seconden heeft ze dan een gedetailleerd ontwerpdocument gemaakt, conform onze standaards voor ontwerpdocumenten. Ik moet zeggen, ik ben erg tevreden over de gemaakte ontwerpen. Goed gestructureerd (conform mijn richtlijnen) en er zitten slimme keuzes in. Ik merk ook dat ze kiest voor "simpele maar effectieve oplossingen". Dat heb ik in haar instructies gezet, en het lijkt erop dat ze daar rekening mee houdt.

Tekst in een ontwerpdocument, geschreven in Markdown. Ontwerp volledig door Gemini CLI "bedacht"; ook de impact en uitwerking van een aanpassing in het thema. Simpel, maar effectief.

Lees het gemaakte ontwerp door, geef aan wat er anders moet, stel vragen en laat de AI het document zelf ook reviewen (kan onverwacht nuttig zijn).

Programmeren

Eindelijk kunnen we de programmacode gaan schrijven of aanpassen, op basis van het technisch ontwerpdocument. Maar programmeren is meer dan alleen code inkloppen. Dit zijn de stappen:

1. code schrijven,
2. testen,
3. oorzaak van de gevonden fouten vinden,
4. de code corrigeren om de gemaakte fouten op te lossen,
5. Ga terug naar stap 2.

Herhaal deze cyclus totdat er geen fouten meer optreden. Dan gaan we verder met het volgende stukje code.

Kan AI helpen? Kan AI helpen bij het schrijven van de programmacode? Ja, redelijk goed, maar wel met enig voorbehoud. We geven de AI de opdracht om de programmacode aan te maken en/of aan te passen, op basis van het ontwerpdocument. En dat gaat ze doen. Heel snel. Heel veel code in korte tijd. Maar ik blijf zelf ook betrokken. Dit is onze taakverdeling:

1. code schrijven: samen met de AI,
2. testen: doe ik zelf,
3. oorzaak vinden van de gevonden fouten: door de AI,
4. de code corrigeren: samen met de AI,
5. terug naar stap 2.

Bij het maken van de code (stap 1) en corrigeren van fouten in de code (stap 4) vind ik het belangrijk om eerst een voorstel van de gemaakte of aangepaste code te zien en die al dan niet goed te keuren. De AI maakt nog weleens foute keuzes (naar mijn mening).

Gemini CLI heeft een voorstel gemaakt voor updates van de programmacode. Ik kan accepteren, afwijzen of aanpassen.

Is het resultaat altijd foutloos? Nee, zeker niet. Er moet getest worden (stap 2). Dit zijn technische testen, uitgevoerd voor het kleine stukje waar we nu aan werken. Meestal worden er fouten gevonden die opgelost moeten worden (stap 3 en 4). Ik vind het belangrijk om de testen zelf uit te voeren. Op die manier blijf je op de hoogte van de werking van het systeem. Doe je dat niet, dan maakt de AI een systeem waarbij je zelf als de betrokken softwareontwikkelaar niet goed weet hoe het werkt.

Ik heb ook gemerkt dat het belangrijk is om bij het corrigeren van de code (stap 4) een vinger aan de pols te houden. Meestal gaat het goed, maar niet altijd. Soms maakt de AI het te ingewikkeld. Of blijft ze rondcirkelen: de foutoplossing introduceert een nieuwe fout en de oplossing voor de nieuwe fout introduceert weer de originele fout.
Soms moet je bij een fout erkennen dat er een ontwerpfout is gemaakt en dat je een andere oplossing moet kiezen. De AI kan dat niet, want zij probeert de opdracht uit te voeren.

Dus af en toe moet je de AI opnieuw laten beginnen. Dat is niet zo erg. Als ik zelf programmeer, kom ik soms ook tot de conclusie dat het beter is om het gemaakte werk weg te gooien en opnieuw te beginnen. Als je iets voor de 2e keer maakt, gaat het altijd veel sneller en is het resultaat kwalitatief veel beter.

Het is belangrijk om het werk in kleine stukjes op te delen, zodat er niet te veel code tegelijk gemaakt wordt. Ik vind het moeilijk om grote hoeveelheden code te beoordelen. En kleine stukjes maken het ook makkelijker om opnieuw te beginnen met dat stukje. Je moet van tevoren wel even nadenken over hoe je een stap terug kunt doen. De aanpassingen, ook van een klein stukje, zitten vaak verspreid over meerdere programmascripts. Je bent zelf verantwoordelijk voor het versiebeheer!

Ik weet nog niet zeker of ik mijn nieuwe rol leuker of minder leuk vind. Programmacode reviewen is wel wat saai en ik mis het zelf schrijven van code. Maar het is wel leuk om steeds op hoofdlijnen te denken.

Veel softwareontwikkelaars vinden routineklussen niet zo heel leuk. Stel, je wilt logging inbouwen in de programmatuur. Dat kan heel nuttig zijn bij het oplossen van fouten. Maar ja, dan moet je in veel programma's dezelfde soort aanpassingen maken. Saai! De AI doet routineklussen heel goed en snel, zonder te mopperen. Dat komt goed uit. Maak in één programma een voorbeeld hoe dat moet en vraag vervolgens aan de AI om hetzelfde te doen voor drie andere programma's. Als dat er goed uitziet, geef dan de opdracht om hetzelfde te doen voor alle andere relevante programma's.

Het is me opgevallen dat de AI eigenlijk staat te trappelen van ongeduld om te gaan programmeren. Terwijl we nog gezellig aan het discussiëren zijn over de beste oplossing, komt ze toch al met de vraag: "Zal ik hiervoor de code genereren?". Het is best lastig om dat ongeduld te beteugelen. Ik heb daarom expliciet in haar algemene instructies gezet: "Bied niet aan om code te genereren. Ik zal hier expliciet opdracht voor geven".

Reviewen

Het is een goede gewoonte dat softwareontwikkelaars elkaars werk reviewen; zowel de ontwerpdocumenten als de gemaakte programmacode. Daarbij lezen collega's mijn gemaakte werk en geven ze mogelijke fouten of verbeterpunten aan. Andersom doe ik dat ook voor collega's. Dat is heel nuttig:

1. Potentiële fouten en verbeteringen worden vroegtijdig ontdekt en kunnen opgelost worden voordat de software "bij de klant ligt",
2. Het zorgt ervoor dat standaards gerespecteerd worden,
3. De schrijver van de documenten of software leert hiervan,
4. De reviewers leren hiervan,
5. De kennis over de nieuwe functionaliteit van het systeem wordt verspreid over de collega's.

Kan AI helpen? Kan AI helpen bij het reviewen van het gemaakte werk? Ja, gedeeltelijk. AI kan helpen bij punt 1. Je kunt de AI vragen om een lijstje met fouten en mogelijke verbeteringen op te leveren.

Vraag aan Gemini CLI om het ontwerpdocument te reviewen

Antwoord van Gemini CLI. Ze geeft een aantal potentiële verbeteringen aan.

Je kunt de AI zelfs vragen om haar eigen werk te reviewen, en dan komt ze meestal ook nog met een nuttig lijstje van fouten en verbeterpunten.

Ook kan ze checken of de gemaakte code voldoet aan onze standaards. Er zijn vele manieren om code te schrijven, maar het is handig als binnen één organisatie iedereen dezelfde stijl van programmeren hanteert. Er zijn programma's ("linters"; geen AI) die de gemaakte code kunnen controleren op programmastijl en een lijst met stijlfouten kunnen opleveren. Je kunt de AI de opdracht geven om de stijlchecker op te starten en alle gerapporteerde stijlfouten op te lossen (= programmacode aanpassen). Als je ook nog oude, ongewijzigde code hebt waarin mogelijk ook nog stijlfouten zitten, dan kun je die ook even door de AI laten oppoetsen. Dat zouden we zelf ook kunnen, maar ja: saai!

Maar het blijft belangrijk dat ook mensen de reviews uitvoeren en de gemaakte producten bekijken, vanwege de leereffecten (punt 3, 4 en 5). Anders kan de situatie ontstaan dat geen enkel mens het systeem meer kent.

Documenteren

Ook zouden programmeurs redelijk wat tijd moeten besteden aan het documenteren van de gemaakte aanpassingen of uitbreidingen in de software. Boven elk stukje programmacode horen een paar regels toelichting ("commentaar") te staan; gewoon in het Nederlands of Engels, waarin kort samengevat is wat die code doet.

Python-programmacode met commentaar (groene en grijze tekst)

Niet elke softwareontwikkelaar ziet het schrijven van documentatie als favoriete bezigheid. Maar het is wel belangrijk, omdat we heel vaak door de programmacode heen bladeren om te begrijpen wat de code doet. Een regel programmacode wordt één keer geschreven en wordt in de jaren daarna honderden keren gelezen; door de auteur zelf en door collega-softwareontwikkelaars. Als een stuk code goede documentatie heeft, dan hoef je alleen die samenvattende documentatie te lezen. Als er geen samenvattende documentatie bij staat, dan moeten we dat hele stuk programmacode doorlezen, analyseren en voorspellen wat de computer met die code gaat doen.

Helaas wordt programmacode vaak aangepast, waardoor mogelijk ook de documentatie weer aangepast zou moeten worden. Dat kost veel tijd en het is saai! Het interessante denkwerk is gedaan. De spanning van het testen (doet ie het of doet ie het niet?) is voorbij. Dan blijft het saaie werk over: het aanpassen van de documentatie.
Het is ook lastig. Soms lees je commentaar en kijk je naar de code, en dan denk je: "dat commentaar klopt waarschijnlijk niet". Maar je weet het niet zeker, en het zou veel tijd kosten om dat grondig uit te zoeken. Die tijd is er vaak niet, want er zijn natuurlijk ook andere problemen die nu echt met hoge prioriteit opgelost moeten worden.

Het bijwerken van het commentaar wordt dus niet altijd gedaan, waardoor de documentatie niet meer precies weergeeft wat de code doet. Als dat vaak gebeurt, dan kun je als softwareontwikkelaar niet meer op de documentatie vertrouwen. Waardoor je toch weer veel programmacode moet lezen, wat tijdrovend is.

Ook ontwerpdocumenten worden aangepast. Bij het programmeren moet je soms toch voor andere oplossingen kiezen dan in het ontwerpdocument beschreven staan. Er kunnen beperkingen zijn die bij het maken van het ontwerp over het hoofd zijn gezien. Dat is de realiteit. Belangrijk is dan dat het ontwerpdocument aangepast wordt, zodat het ontwerpdocument weer de actuele stand van zaken weergeeft.

Kan AI helpen? Kan AI daarbij helpen bij het documenteren? Jazeker, heel goed. Het maken van een toelichting (commentaar) op de programmacode komt neer op het samenvatten van de programmacode. En AI is heel goed in het samenvatten van teksten. Voor zover ik kan inschatten, vindt ze het ook niet saai. In mijn AI-project heb ik de AI opdracht gegeven om alle programmacode te voorzien van up-to-date documentatie. Ook kan ze heel goed ontwerpdocumenten bijwerken.

Testen

Tijdens het programmeren testen we veel. Dat is belangrijk, want de nieuwe functionaliteit moet natuurlijk wel goed werken. Maar het is nog veel belangrijker dat de oude functionaliteit goed blijft werken. Want die nieuwe functionaliteit is meestal maar voor een klein deel van onze klanten, terwijl de rest van de functionaliteit door alle klanten gebruikt wordt. En het gebeurt helaas vaak dat er bij het maken van nieuwe functionaliteit fouten in oude functionaliteit ontstaan.

Er moeten dus nog veel meer testen uitgevoerd worden. Vaak zullen dat automatische testen zijn. Automatische testen zijn speciaal voor dit doel ontwikkelde computerprogramma's die als taak hebben het testen van bepaalde functionaliteit in het systeem. Een voorbeeld:

Een automatische test voert achtereenvolgens de volgende stappen uit:

1. slaat gegevens van een nieuw Product op in het systeem,
2. wijzigt de gegevens van dat Product,
3. verwijdert het Product en
4. probeert het Product nog een keer te verwijderen.

Stap 1), 2) en 3) moeten foutloos verlopen; stap 4) moet een nette foutmelding geven, zonder dat het systeem vastloopt. Deze automatische test wordt bijvoorbeeld uitgevoerd voor 20 testcases. Elke testcase voert deze test uit voor een ander type Product, met andere eigenschappen.
Automatische testen worden vaak 's nachts uitgevoerd. Als ik vandaag een fout introduceer, dan wordt die de komende nacht (hopelijk) ontdekt door de automatische testen. En morgenochtend, nog voordat ik mijn eerste koffie op heb, heb ik al een automatische mail ontvangen over die fout. Dan kan ik het misschien nog repareren voordat de collega's er last van hebben.

Kan AI helpen? Kan AI helpen bij het maken van testen? Jazeker, AI kan daarbij helpen. De AI kan de ontwerpen maken voor de automatische testprogramma's en kan op basis daarvan testprogramma's zelf maken en documenteren. In essentie is dit een klein programmeerproject.

Fouten oplossen

Ook besteden we veel tijd aan het oplossen van fouten ("bugs"). Fouten die we zelf vinden bij het testen van de gemaakte of gewijzigde programmacode. Fouten die gevonden worden door de automatische testen. En ja, soms ook fouten die door klanten gevonden worden.

Soms zijn het fouten die jaren en jaren geleden al ingebouwd zijn, nooit tot problemen hebben geleid, totdat het ineens bij één klant misgaat. Daar zit dan vaak een bijzonder verhaal achter. Bijvoorbeeld een zeer ongebruikelijke combinatie van een heel oude versie van de database in combinatie met een gloednieuwe versie van het operating system.

Bij het oplossen van een fout besteden we heel veel tijd aan het lezen en begrijpen van programmacode. Het programma voert misschien wel duizenden regels code uit. Ergens zit er iets fout, maar waar? Soms voelt het als het zoeken van een speld in een hooiberg.

Gelukkig zijn er allerlei hulpmiddelen die dit zoeken makkelijker maken, bijvoorbeeld een debugger of logfiles. Maar toch, het blijft zoeken en er gaat veel tijd in zitten. Als je het dan eenmaal gevonden hebt, dan ben je eerst blij: "Yes! Gevonden!". Maar de tweede gedachte is dan toch ook vaak: "O, wat dom. Ik heb er wel 10 keer overheen gelezen."

Soms zijn we wel een hele dag bezig met het oplossen van één fout. En dan kan het voorkomen dat die fout opgelost wordt door 1 letter te veranderen in de programmacode. Als onze manager dan vraagt: "Wat is je productiviteit?", dan is het antwoord: "Ongeveer 1 letter per dag". Gelukkig zijn er ook dagen met een hogere productiviteit.

Kan AI helpen? Kan AI helpen bij het oplossen van fouten? Jazeker, AI kan daar heel erg goed bij helpen. De AI is geen domme find-button waarmee je naar een bepaalde string kunt zoeken, maar ze lijkt een inhoudelijk begrip te hebben van de situatie en de programmacode. En ze leest nergens overheen.

Als je de fout gedetailleerd beschrijft met een screenshot van de fout erbij en een beschrijving van wanneer die fout wel optreedt en wanneer niet, dan heb je een redelijke kans dat de AI de fout meteen vindt. Geef haar eventueel de logfiles erbij, want ze is ook heel goed in het analyseren van logfiles. Als ze het toch niet kan vinden, dan geeft ze vaak aan wat er nog nodig is om de fout wel te vinden: bijvoorbeeld wat extra informatie in de logfiles.

Conclusie

Hierboven heb ik de belangrijkste werkzaamheden van een softwareontwikkelaar beschreven. En bij al die werkzaamheden kon AI helpen; vaak kon ze zelfs heel goed helpen.

Mijn conclusie is dat AI heel goed kan helpen bij het ontwikkelen van software.

Waarom is AI juist zo goed in softwareontwikkeling? Een programmeertaal is een taal, net zoals Nederlands en Engels; misschien nog wel makkelijker. De kern van de huidige AI-producten zoals Gemini CLI wordt gevormd door zogenaamde Large Language Models (LLMs). Die zijn heel erg goed in het "begrijpen" en maken van teksten. Softwareontwikkeling is eigenlijk alleen maar werken met teksten: documenten en programmacode. Daarom is AI een heel goed hulpmiddel bij softwareontwikkeling.

AI kan op basis van een Engels document een Nederlandse samenvatting schrijven. Het is dan ook niet zo gek dat AI Python-programmacode kan samenvatten in het Engels (= documenteren van code). Je kunt de AI vragen een verhaal in het Engels te schrijven op basis van specifieke instructies in het Nederlands. Het is ook wel te begrijpen dat je AI de opdracht kunt geven om een programma te schrijven in bijvoorbeeld de programmeertaal Python op basis van een Engelstalig document met instructies.

AI heeft een paar zwakke punten:

• AI is niet zo heel betrouwbaar. Ze maakt fouten. Het klinkt misschien gek, maar juist in de software business is dat niet zo erg. We zijn het gewend. Softwareontwikkelaars maken ook fouten. Daarom hebben we kwaliteitsprocedures (reviewen, testen, automatische testen, etc.). Die procedures moeten we zeker in stand houden als we met AI-software gaan ontwikkelen.

• AI "verzint" soms dingen ("hallucineren"). Dat gebeurt als ze niet genoeg informatie heeft; dan maakt ze een "educated guess". Ik vind dat eigenlijk wel goed. Het alternatief is dat ze vaak zou zeggen: "Sorry, ik heb niet genoeg informatie om deze opdracht uit te voeren". Als ik zelf programmeer, dan maak ik ook voortdurend inschattingen en aannames. Als ik dat niet zou doen, dan zouden mijn opdrachtgevers helemaal gek worden van al mijn vragen.

• AI is niet altijd consistent. Vandaag kan ze voor hetzelfde probleem een heel andere oplossing kiezen dan gisteren. Dat kan verschillende oorzaken hebben: vandaag hebben we misschien ongemerkt een iets andere versie van de AI dan gisteren, onze vraagstelling kan vandaag net iets anders zijn dan gisteren, de volgorde van onze vragen kan anders zijn, etc. Maar ook dat is niet zo erg in de softwareontwikkeling. Vaak zijn er meerdere goede oplossingen voor één probleem. Je kunt het ook sturen door de instructies en de opdrachten (prompts) gedetailleerder te maken.

Deze zwakke punten zijn vooral gevaarlijk als de resultaten van de AI direct naar de eindgebruikers zouden gaan. Als ik aan ChatGPT vraag hoe ik de accu van mijn auto kan verwisselen, dan kan het antwoord maar beter correct zijn, zonder verzinsels. Als ze het niet weet, dan moet ze dat gewoon aangeven.

Maar juist in de context van professionele softwareontwikkeling zijn deze zwakke punten van de AI niet zo hinderlijk. Het resultaat gaat niet direct naar de eindgebruiker en er zijn test- en reviewprocedures. Het maken van "educated guesses" is juist een sterk punt.
Dit versterkt alleen maar de conclusie dat AI heel geschikt is voor de ontwikkeling van software.

Een jonge, veelbelovende programmeur

Ik zie AI als een veelbelovende en hardwerkende juniorprogrammeur, die heel snel kan zoeken in teksten. Ze begrijpt veel talen, ook programmeertalen. Uiteraard beheerst ze niet alle programmeertalen even goed.

Ze kan teksten maken en aanpassen op basis van specificaties. Ze kan heel snel teksten samenvatten. Ze kan documenten maken conform onze standaards. Ze kan teksten vertalen, bijvoorbeeld van Nederlands naar Python en andersom. Ze kan daarom heel snel heel veel programmacode maken.

Blijkbaar vindt ze programmeren erg leuk, want ze is ongeduldig en wil al programmacode maken als we nog met het ontwerp bezig zijn. Kortom: jong en enthousiast. Maar ze vindt het ook niet erg om saai werk te doen.

Als junior kiest ze niet altijd voor de handigste oplossing. Ze moet daarom wel goed aangestuurd en gecontroleerd worden door ervaren (menselijke) programmeurs. Het lijkt me niet goed dat een menselijke junior-programmeur een AI (ook een junior) gaat aansturen. Dan krijg je onvolwassen code. Daarom blijft het belangrijk dat menselijke junior programmeurs nog steeds de gelegenheid krijgen uit te groeien tot ervaren programmeurs.

Zoals elke softwareontwikkelaar maakt de AI ook fouten. Haar werk moet getest en gereviewd worden. Het blijft heel belangrijk om de bestaande kwaliteitssystemen en -procedures te blijven gebruiken en misschien zelfs uit te breiden.

Om deze jonge, veelbelovende programmeur goed aan te sturen, moet je veel tijd investeren in het maken van instructies en richtlijnen (prompts).

Wat mij betreft heeft de AI zich bewezen in dit project. Met haar erbij ging het sneller en beter. Wel moet ik de kanttekening maken dat dit om een klein systeem ging. In grote systemen is het altijd moeilijker en ingewikkelder om nieuwe junior-collega's en nieuwe technieken in te zetten.